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Abstract —This paper presents FAIR, a forwarding account¬ 
ability mechanism that incentivizes ISPs to apply stricter security 
policies to their customers. The Autonomous System (AS) of the 
receiver specifies a traffic profile that the sender AS must adhere 
to. Transit ASes on the path mark packets. In case of traffic 
profile violations, the marked packets are used as a proof of 
misbehavior. 

FAIR introduces low bandwidth overhead and requires no 
per-packet and no per-flow state for forwarding. We describe 
integration with IP and demonstrate a software switch running 
on commodity hardware that can switch packets at a line rate 
of 120 Gbps, and can forward 140M minimum-sized packets per 
second, limited by the hardware I/O subsystem. 

Moreover, this paper proposes a “suspicious bit” for packet 
headers — an application that builds on top of FAIR’S proofs 
of misbehavior and flags packets to warn other entities in the 
network. 


I. Introduction 

The frequency and intensity of attacks rooted in miscon- 
figured or vulnerable Internet services has increased in the last 
months: in February 2014, attackers abused misconfigured time 
synchronization servers in to attack Cloudflare with a peak of 
400 Gbps 0. For 2014, Akamai reports a 90% increase in total 
DDoS attacks and a 52% increase in average peak bandwidth 
compared to the previous year 0. Moreover, man-on-the-side 
script injection attacks |4j] and vulnerable web services have 
been used as general-purpose attack vectors 01). 

These events are explained by the following observations. 
First, the lack of accountability in today’s Internet facilitates 
attacks with spoofed addresses, allowing attackers to evade 
blocking mechanisms. Second, the architectural limitations of 
today’s Internet lead to insufficiently effective DDoS defense 
mechanisms. Third, ISPs have no incentive to punish their mis¬ 
behaving customers, nor to monitor them. Typically, monitor¬ 
ing comes with high storage and computational requirements 
that yield additional costs for network operators. 

In order to address these problems, the security community 
has considered several solutions, which come with certain 
shortcomings: source accountability schemes encounter 

routing scalability problems and introduce prohibitive band¬ 
width overhead; cloud-based retroactive DDoS defense ser¬ 
vices introduce latency and are insufficiently effective, yet 
prices can exceed several thousand dollars per month (9 ]; capa¬ 
bility schemes Dana introduce complexity and require per- 
flow operations; extensive filtering Q3HH 0 requires operator 
vigilance and out-of-band coordination among ISPs. 


Although we stand in solidarity with these proposals, this 
paper takes a different approach and proposes a lightweight 
scheme that incentivizes ASes to solve their security problems. 
To this end, we leverage forwarding accountability. In a 
nutshell, the key idea behind forwarding accountability is to 
hold ASes accountable for the traffic they forward; transit ASes 
embed proofs in the packets such that, in case of malicious 
traffic, a destination AS can later use these proofs to show to 
the transit ASes that they have indeed forwarded the malicious 
traffic. We stress that transit ASes do not store any information, 
but given proofs of misbehavior they can deprioritize traffic 
from provably malicious ASes. This protects the victim and 
increases capacity for benign traffic. 

We take volumetric DDoS attacks as one possible use 
case and demonstrate the virtues of forwarding accountability. 
Consider the topology depicted in |Figure 1| and assume web 
servers, or even servers of critical infrastructures, are located 
inside AS n . We assume, exactly as happened in 2014 0, that 
an attacker launches a reflection attack against the victims 
by exploiting the NTP protocol running on misconfigured 
servers. More precisely, the attacker fakes the victim’s source 
IP address and sends NTP commands to the misconfigured 
NTP servers within ASo- The NTP servers reply to the victim 
with responses that are up to 200 times larger than the initial 
rogue requests, overpowering the victim’s resources. With 
forwarding accountability in place, the transit ASes embed 
proofs in the packets that will remind them later that they 
forwarded the traffic. When the victim reports the attack to 
transit ASes (ASi and ASi) by providing the proof, the transit 
ASes acknowledge that they indeed forwarded the malicious 
traffic. It then becomes evident that ASo sourced the malicious 
traffic, namely from the misconfigured NTP servers. ASi can 
then drop (or at least deprioritize) ASo’s traffic and thus protect 
not only AS n and its servers, but also all networks between 
ASo and AS n . This approach provides benefits also in sparse 
deployment, where only one transit AS accepts proofs of 
misbehavior and takes action. Hence, adoption does not require 
coordination among ISPs. 

A cost-effective incremental deployment path is critical to 
the success of any practical security scheme. ISPs’ willingness 
to adopt security mechanisms is motivated by their reputation 
and the competitive market environment D3, but constrained 
by the additional expenses and the lack of economic incen¬ 
tives B18I . In addition, recent Internet regulations lH9l intend 
to actively involve ISPs in stopping the dissemination of 
malicious traffic, thus making security mechanisms a necessity 
in the near future. Despite regulatory pressure for adoption of 
security mechanisms, efficiency and incremental deployment 
remain important properties that drive adoption. 




Contributions. This paper proposes an architectural mecha¬ 
nism, FAIR, to achieve Forwarding Accountability for Internet 
Reputability. The key concept is that transit ASes embed short 
cryptographic markings in the packets that will later prove 
to the ASes that they forwarded these packets. In case of 
malicious traffic, destination ASes can use these proofs to show 
to transit ASes that they have indeed forwarded the malicious 
traffic. After acknowledging the proof of misbehavior, the 
transit ASes can deprioritize traffic from malicious ASes, 
increasing network capacity for benign sources. 

FAIR is founded on a strong threat model where source, 
destination, and transit ASes can be compromised or malicious. 
Moreover, FAIR has the following properties: 

• low overhead for processing and bandwidth. 

• no per-packet and no per-flow state for forwarding. 

• simple key management with one shared key between 
source and destination ASes. 

• deployment compatibility with IP networks. 

• complementary applicability to DDoS defense 
schemes. 

We have designed and implemented a software switch 
performing FAIR packet marking that operates at line rate of 
up to 120 Gbps; it forwards 140M minimum-sized packets per 
second on a commodity machine, which is currently limited 
by the hardware I/O subsystem. 

With FAIR in place, we reconsider Bellovin’s April Fool 
proposal of the “evil bit” 11201 and propose an extension to 
our proposal, the “suspicious bit”: ASes that forward traffic 
from misbehaving customers mark this traffic as suspicious, 
informing other entities in the network. The suspicious bit 
provides a strong incentive for an AS to watch its traffic and 
mark malicious traffic itself with the suspicious bit, otherwise 
its upstream ISP may mark all of the AS’s traffic as suspicious, 
thus, causing collateral damage to benign senders. 


II. Overview of FAIR 


Before describing our assumptions and protocol details, 
we first present a high-level overview of FAIR. Our proposal 
combines ideas from capability systems EMU and traceback 
mechanisms ED, yet its approach is fundamentally different: 
instead of carrying capabilities, packets collect proofs that will 
remind transit ASes of having forwarded these packets. In case 
of malicious traffic, the destination AS sends the proofs back 
to the transit ASes. Communication under FAIR proceeds in 
three phases. These are depicted in |Figure 1 using a line- 
network topology with cooperating ASes (gray circles) and 
non-cooperating ASes (black circles Q. Cooperating ASes are 
ASes that support FAIR, which, however, does not imply 
benign behavior. 


• Phase 1 (Setup): Source and destination ASes set 
up a communication channel and agree on a sending 
policy that governs the aggregate traffic from the 


'This is a simplified communication model, which assumes that all flows 
from the source to the destination AS follow the same AS path. We will relax 
this assumption later. 



Fig. 1: Communication under FAIR. 


source AS to the destination AS over a specific AS 
path. Such a policy can specify the average sending 
rate, the maximum burst size, or even forbid abnormal 
packet headers that are used for OS fingerprinting and 
flooding attacks (e.g., Christmas tree packets 1221 ). 

• Phase 2 (Transmission): The source sends data pack¬ 
ets to the destination over the communication channel. 
Each cooperating transit AS inscribes minimal infor¬ 
mation in the packet headers, which serves as a proof 
to itself that it has forwarded the packets. 

• Phase 3 (Protest): If the destination AS detects a 
policy violation, it proceeds to the protest phase and 
provides the sending policy together with the data 
packet headers to the transit ASes, as a proof of 
misbehavior. This proof of misbehavior identifies the 
adversary. 

Setting up a sending policy specifies the sending properties 
of the aggregate traffic from the source AS to the destination 
AS. A violation implies that the source AS is compromised, 
malicious, or has poor security practices. A destination AS, 
depending on its security policies, can drop traffic from source 
ASes that do not set up a sending policy. Transit ASes receive 
the proof of misbehavior and can deprioritize inappropriate 
traffic, depending on their policies. In the DDoS use case, a 
destination AS establishes a traffic profile with its source ASes 
and specifies the receiving rates according to its resources. 
Hence, in case of an attack, the destination AS can prove to 
transit ASes the sending rate violations. 

A. Setup (Phase 1) 

Source and destination ASes set up a channel with a send¬ 
ing policy P for traffic from the source AS to the destination 
AS. The sending policy is formally expressed by the Token 
Bucket (TB) parameters ll23l that the source AS should use for 
traffic shaping towards the destination AS. In the TB algorithm, 
a fixed-sized bucket is filled with tokens at a certain rate. A 
token represents a permission to send a specific number of 
bits. For a packet transmission, a number of tokens equal to the 
packet size is removed from the bucket. If there are not enough 
tokens, the packet either waits for more tokens (shaper) or is 
discarded (policer). The TB is the formal description of the 
properties of a transmission. It allows burstiness, but bounds 
it, as the maximum burst size is proportional to the bucket 
size. 















More specifically, the destination AS specifies two param¬ 
eters: the Committed Information Rate ( CIR ), i.e., the average 
amount of data sent per time unit; and the Committed Burst 
Size ( CBS), i.e., the maximum amount of data that can be sent 
(for a given time interval). The time interval ( T c ) is determined 
through the relation CIR = CBS/T c . Using these values, the 
sending policy is then established as follows: 

i. The source AS constructs a sending policy packet and 
sends it to the destination AS. 

ii. Each cooperating transit AS indicates its presence on 
the path. It does not interfere with the sending policy 
details, nor does it keep per-policy state. 

iii. The destination AS completes the sending policy by 
filling in the CIR and CBS values and returns the 
information to the source AS. 

This is merely an example of a policy construction to 
demonstrate the necessary information to prove misbehavior 
in the data plane, which is our focus. For example, to handle 
temporary increased traffic volumes (e.g., during popular sport 
events) the source AS can renegotiate the policy’s properties 
and request more bandwidth. 

The setup phase can also be substituted by other future In¬ 
ternet proposals. For example. Route Bazaar ll24l uses publicly 
verifiable multilateral contracts among ASes; SCION ||25l[26l 
provides explicit path-validation information for AS paths. 

B. Data Transmission (Phase 2) 

We describe the data-plane operations performed by source 
ASes, cooperating ASes, and destination ASes. These opera¬ 
tions are applied to each data packet. 

Source AS. The source sends data packets over the known 
path. Border routers of the source AS enforce the sending pol¬ 
icy by applying the parameters to the Token Bucket. Moreover, 
they embed additional information in the packet, including a 
sequence number and a sending time. This information is used 
at a later stage to construct a proof of a violation. 

Transit ASes. Each egress border router of a cooperating 
transit AS performs the following operations upon packet 
reception: 

i. The border router verifies that the source’s timestamp 
in the packet is recent and does not deviate from the 
local time beyond a threshold, otherwise the border 
router drops the packet. 

ii. The border router marks the packet, indicating that 
it has “seen” the packet. The marking is crypto¬ 
graphically protected with a message authentication 
code. Since each marking is used to remind only the 
corresponding AS that inscribed it, it is computed 
with a secret key that is only known to the AS. 
This marking is used in the third phase to remind 
the corresponding AS that it indeed forwarded the 
packet. 

Destination AS. The destination AS monitors the communi¬ 
cation channel and performs traffic policing to detect sending 
policy violations. It stores only packet headers as they contain 
the markings for the proof of misbehavior, which enables the 


corresponding transit ASes to acknowledge that they indeed 
forwarded the packets. If a violation is detected, the destination 
uses the received packets and proves misbehavior to the transit 
ASes. 

C. Proving Misbehavior (Phase 3) 

The goal of Phase 3 is to enable destination ASes to prov- 
ably protest to other ASes. Taking action against misbehavior 
is a decision that a destination AS makes according to its 
interests and policies. Complaints for malicious behavior is 
an offline procedure between the destination and the transit 
ASes. The procedure occurs in two rounds. 

First, the destination provides the sending policy and the 
data packet headers to all cooperating ASes on the path. The 
sending policy contains the transmission properties (CIR and 
CBS) for the communication channel. The data packet headers 
contain information for the actual transmission properties. 
The ASes examine the evidence and acknowledge or reject 
the complaint. An approved complaint means that the AS 
acknowledges that it forwarded inappropriate traffic compared 
to the sending policy specification. This, however, does not 
mean that the source AS is malicious. For example, if a 
transit AS injects packets, the source is not responsible for the 
violation. The destination AS collects approved and rejected 
complaints from the transit ASes. 

In the second round, the destination AS sends all the col¬ 
lected information back to the ASes. Based on this information, 
the ASes on the path conclude whether the source AS is 
compromised or whether there were attempts to falsely blame 
an innocent source. In ISection IV-Al we explain situations with 
malicious transit ASes. 

III. The FAIR Protocol 

We make certain design choices that construct a lightweight 
accountability mechanism: 1) proofs of misbehavior are car¬ 
ried in data packets, allowing stateless forwarding for transit 
ASes; 2) probabilistic detection of misbehavior introduces 
minimal overhead per-packet (a few bytes), keeping bandwidth 
overhead low; 3) all data-plane cryptography is symmetric, 
degrading forwarding performance marginally. 

A. Assumptions 

• The source knows the AS-level path to the destination 
and also knows which ASes on the path deploy the 
mechanism. BGP update messages contain the AS- 
level path in the AS-path attribute l27l and cooper¬ 
ating ASes can advertise their support for FAIR in 
their BGP announcements as a transitive attribute. 

• Participating parties can obtain and authenticate the 
public keys of all cooperating ASes. We leverage 
RPKI ll28l . a PKI framework that enables entities to 
authenticate resource certificates (issued by Regional 
Internet Registries) that bind Autonomous System 
Numbers (ASNs) to the corresponding public keys, 
given the correct RPKI public root key. 

• Source and destination ASes perform traffic shaping 
and policing based on the Token Bucket algorithm . For 
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Fig. 2: FAIR Packet Header. 



example, Cisco’s shaping mechanisms (Generic Traf¬ 
fic Shaping, Class-Based Shaping, Distributed Traffic 
Shaping) and policing mechanisms (Committed Ac¬ 
cess Rate, Traffic Policing) are based on the Token 
Bucket 11231 . 

Furthermore, we assume that the cryptographic mecha¬ 
nisms are secure, i.e., cryptographic hash functions cannot be 
inverted, signatures cannot be forged, and encryptions cannot 
be broken. 

B. Parameters 

Cryptographic Operations. Source and destination ASes 
establish a secret key (Ksd) between them and cache the 
key to avoid redundant computations. To establish the key, 
they can obtain the public keys from the RPKI and use a non¬ 
interactive Diffie-Hellman key exchange H29 | [30 ] . Furthermore, 
each transit AS; uses two local secret keys that can be changed 
independently from the other ASes: one long-term key for 
control-plane operations (K,) and one key for data-plane 
operations (A',). These local secret keys are independent of 
the communication channels that traverse the AS. Furthermore, 
transit ASes keep the previous keys for at least T m = 12 hours 
to be able to verify proof that refers further to the past. 

Protest Time Margin ( T m ). The destination can protest right 
after a violation is detected or defer the process to a later 
point in time. However, we set a time margin after which 
transit ASes are not obliged to examine proofs of violations, 
to avoid situations where complaints refer to violations too far 
in the past. The value for this parameter is agreed upon and 
universally known to the cooperating ASes. There is no strict 
requirement for choosing this value; we use T m = 12 hours 
so that ASes have a loose time window to prove misbehavior. 

Clock Deviation. We assume loose clock synchronization 
between ASes and a reference clock can be set up with an 
error less than 0.5 seconds; GPS can provide sub-microsecond 
precision ED- Furthermore, we assume that the end-to-end 
packet latency (propagation, transmission, queuing, and pro¬ 
cessing delay) does not exceed one second. 

Reported timestamps in packets are at the granularity of 
seconds, hence packets with timestamps that differ more than 
three seconds from the local time at each router are dropped. 
This check ensures that the timestamps in the packets are fresh 
and can be used in the protest phase. The three-second margin 


Fig. 3: Summary of Symbols and Notation 
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ensures that packets will not get dropped due to boundary 
effects when the end-to-end latency and the clock difference 
add up (one second maximum clock difference between ASes, 
one second maximum end-to-end latency, and one second due 
to possible boundary effects during clock transitions). 


C. Protocol Operations 

We describe the required operations starting with the data 
plane, which realizes our notion of forwarding accountability. 
Then, in the control plane, we present a low-latency channel 
setup and the corresponding sending policy construction. In the 
end, we show how the sending policy and the data packets are 
used to prove misbehavior. |Figure 3| summarizes the notation 
we use throughout the paper. 


1) Data Plane. First, we show the necessary information 
and then the interactions between the involved entities. The 
information and operations described in this section apply to 
every data packet. Figure 2 shows the corresponding FAIR data 
packet header. 


• Source Timestamp: an indication for the time when the 
packet has left the source AS. It is a 16-bit value at the 
granularity of 1 second. It suffices to capture durations 
up to 18 hours, hence it constrains the possible values 
for the Protest Time Margin T m (we have chosen 
T m = 12 hours). 

• Sequence Number: a 24-bit monotonically increasing 
packet counter inserted by the source AS. The first 
packet of a communication channel gets the value 0. 

• Integrity Check Value (MACif SD ): an 8-bit MAC over 
the payload-length field (in the network-layer header) 
and the other FAIR related information inserted by the 
source AS (source timestamp and sequence number). 
The purpose of the MAC is to signal on-path header 
modification; it is computed with the shared key Ksd- 
Although the MAC length is short, we do not use the 
MAC to provide integrity guarantees per packet, but 
to signal misbehavior over an aggregate of packets. In 
ISection IV-AI we quantify the security implications 
of this idea. The payload length is included in the 
computation of the ICV so that the destination stores 
packet headers only, not the whole packets. 











• Nonce fields: a 4-bit value inserted by each AS on the 
path. It functions as an indicator of having forwarded 
the packet and to enable detection of replay attacks; 
the values are chosen uniformly at random. 

• MAC fields (MAC/<-,): a 4-bit MAC inserted by each 
AS on the path. The input to the MAC is the in¬ 
formation that must be integrity-protected to securely 
prove a sending-rate violation in the protest phase: 
the packet length in the network-layer header, the 
source’s timestamp and sequence number in the FAIR 
header, and the nonce field. The local secret key K, 
used to compute the MAC is maintained by each 
AS independently. As described earlier, we use short 
MACs to signal misbehavior over an aggregate of 
packets. We will show that even a 1-bit MAC can be 
used for our purpose (ISection IV-Ab . If a subsequent 
entity changes any of the previous information in the 
packet, the MAC verification will fail. 

• NextAS: an 8-bit pointer to the position in the FAIR 
header where the next AS on the path will insert its 
information. The pointer is initialized by the source 
and each transit AS modifies it accordingly. The 8-bit 
field suffices for inter-domain paths up to 256 hops; 
the average AS-path length today is 3.9 hops (3.5 
hops) for IPv4 (IPv6) ll32l. 

The sequence numbers, timestamps, and nonces are used 
to provide loose replay detection at the AS-level granularity. 
Replay detection reveals such an attack in the protest phase; 
the purpose is not to have the destination AS drop replayed 
packets. The monotonically increasing values of the sequence 
numbers together with the timestamp values are used to detect 
replay attacks. Multiple occurrences of a sequence number 
for the same timestamp reveal the replay. Furthermore, the 
clock deviation check at each AS hop prevents an attacker 
from storing and replaying the packet at a later point in time. 
The random nonces inscribed by each AS provide information 
about the adversary’s position on the path. Nonces localize 
the adversary to a portion of the path, depending on which 
nonce fields repeat and which change per replayed packet. 
Furthermore, the short MAC fields serve as a misbehavior 
flag (rather than as integrity guarantees per packet): a few 
verification failures in the protest phase indicate misbehavior. 
Sections IlII-DI and IIV-AI provide further details. 

Processing of Outbound Packets: The source AS creates a 
FAIR packet header and fills in its information. The new packet 
header is placed between the network and transport-layer 
headers and is created with a sufficient length to accommodate 
the information of the transit ASes; this ensures that the packet 
length does not increase en route. The AS-level path is known 
to the source AS, and each transit AS overwrites 1 byte of 
the header. Based on the destination address in the packet 
header, the border router of the source AS determines the 
shared key with the destination AS, the current packet count 
for this communication channel ( seqno ), and the output port to 
forward the packet to. IProcedure II summarizes the operations 
that the source performs. 

Processing of Forwarding Packets: We describe the actions 
that each egress border router of the cooperating ASes on the 
path (AS;, 1 < i < n) performs for each data packet. 


Procedure 1: Processing of Outbound Packets 

procedure SEND (pkt, pkt_hdr, fair) 

> pkt refers to the whole packet 

> pkt_hdr contains the network-layer packet header 

> fair[ ] is the FAIR header that the source creates 

> cut the packet counter per communication channel 

(port, Ksd, cn t) lookup (pkt_hdr) 

fair[0].time <— time()|(i6\ 

fair[0).seqno 4 — ++cnt\( 24 ) 

fair[0].icv <— MAC k SD (pkt _hdr. pay load _len 

|| fair[0].time || fair[0].seqno)\^ 

fair.nextAS <— 0 
transmit(p&;£, port ) 


Procedure 2: Processing of Forwarding Packets 

procedure FORWARD(p/c£, pkt_hdr, fair) 

> pkt refers to the whole packet 

> pkt_hdr contains the network-layer packet header 

> fair[ ] is the FAIR header 

diff <- | fair[0].time - time()|( 16 )| 
if diff > 3 and diff < 2 16 — 3 then 
drop packet 

fair[i],nonce <— rand()|( 4 -* 

++fair.nextAS 

fair[i].mac <— MAC i<.(pkt_hdr.payload_len || fair[0].time 
|| fair[0].seqno || fair [i], nonce )|( 4 ) 
port <— lookup(pkt_hdr) 
trasmit(pA:4, port ) 


i. Check the source’s timestamp in the received packet 
and compare it with the local time. If the difference 
is greater than 3 seconds, drop the packet, otherwise 
forward the packet according to Step (ii). Step (i) 
ensures that the source is not indicating false times¬ 
tamps. 

ii. Add a short nonce (4 bits) and a MAC (4 bits) at the 
corresponding AS-specific position in the header. 

iii. Increment the next AS pointer. 

Note that transit ASes do not need to perform destination- 
based key switching since they use their local secret to mark 
transit traffic. A non-cooperating AS ignores the FAIR header 
and forwards the packet according to the destination address. 
IProcedure 21 summarizes these operations. 

Processing of Inbound Packets: The destination performs the 
following data-plane operations: 

i. Check the timestamp, similar to transit ASes. 

ii. Detect sending policy violations per established com¬ 
munication channel. This is straightforward by using 
Token Bucket as a policer, given the CIR and CBS 
values. 

iii. Verify MACif sc to ensure that the source’s informa¬ 
tion has not been modified en route. 

The destination stores the packet headers (network-layer 
headers and FAIR headers) as they contain potential proofs of 
misbehavior. IProcedure 31 summarizes these steps. 

2) Control Plane. We present a policy setup that introduces 
no latency in the data plane between the communicating end 
hosts of source and destination ASes. The setup is based on 
two concepts. First, ASes advertise their IP prefixes through 
BGP together with a default sending policy that is used until 




















Procedure 3: Processing of Inbound Packets 

procedure RECElVE(pkt_hdr,fair ) 

> pkt_hdr contains the network-layer packet header 

> fair[ ] is the FAIR header 

diff «- | fair[0].time - time()|( 16 )| 
if diff > 3 and diff < 2 16 — 3 then 
drop packet 

icv 4— MAC fc SD (pkt_hdr.payload_len 

|| fair[0].time || fair[0].seqno)\^ 
if icv f fair[0].icv then 

drop packet 


source and destination ASes establish a new sending policy 
with different properties. Second, using mostly symmetric- 
key cryptography keeps the setup latency low. Specifically, 
only source and destination ASes sign the sending policy 
with their private keys, making the policy details provable 
and non-repudiable. Transit ASes insert MACs that remind 
them of being on the path of the communication channel. The 
combination of the aforementioned concepts allows end hosts 
to communicate without waiting for a sending policy setup and 
guarantees that the latency of the setup remains low. 

First, we summarize all the information that is required and 
then we show how the policy is constructed. 

• Current timestamp: inserted by the source AS, indicat¬ 
ing the current time as the start for the communication 
channel. 

• Expiration timestamp: inserted by the destination AS, 
indicating the end of the communication channel. 

• Token Bucket properties: CIR and CBS values are 
inserted by the destination AS and specify the sending 
properties for the source (see ISection II-AI ). 

• FAIR-AS path: the source AS inserts the list of 
cooperating ASes on the path to the destination, which 
is known through the BGP advertisements. 

• Autonomous System Numbers: each AS on the path 
inserts its own ASN that serves as an identifier. 

• Signatures: source and destination ASes insert a sig¬ 
nature over the policy details. 

We provide more details about how this information is used. 

The source AS creates a policy packet ( P ) and sends it to 
the destination AS. P\0] corresponds to information inserted 
by the source AS and P[n\ to information inserted by the 
destination AS. 

i. The source AS creates a policy packet P, with a 
timestamp indicating the start for the communica¬ 
tion channel. Moreover, the source inscribes its Au¬ 
tonomous System Number ASNq, the current time, 
the cooperating ASes on the path, and signs all the 
information with its private key PKf . In particular, 
to avoid length-dependent security issues with signa¬ 
tures the hash of the information is signed (33]. 

P[0].asn 4— ASNo 
P[0\.time 4— time() 

P[0].path 4— AS_path 

P[0].sig -4— Sign o (H(P[0].asn || P[0].time || P[0].path)) 


ii. Each transit AS;, 1 < i < n, indicates its presence 
on the path. It adds its ASNi and inserts a MAC over 
all the previous information. The MAC is computed 
with a long-term local secret ( K,), known only to 
AS;, that is used for control-plane operations. 

P[i].asn 4— ASNi 

P[i\.mac 4— MAC K. (H(.P[0] || ■ • ■ || P[i — 1 ] || P[i].asn 

iii. The destination AS receives P and leverages the 
RPKI to verify the signature of the source AS. If 
verification succeeds, it fills in its ASN n , the expira¬ 
tion time, and the Token Bucket values of CIR and 
CBS. The destination signs the contents of the final 
sending policy and sends it back to the source AS. 

P[n].asn 4 — ASN n 
P[n\.expiration 4— futureTime 
P[n].CIR 4 — CIR 
P[n].CBS 4 — CBS 

P[n\.sig 4— Sign n (H(P[0] || • • • || P[n — 1] || P[n\.asn 

|| P[n\.expiration || P[n].CIR || P[n].CBS)) 

iv. Source and destination ASes use the RPKI and per¬ 
form a non-interactive Diffie-Hellman key exchange 
to derive a shared key ( K$d ) between them. 

Note that transit ASes do not store information about 
the sending policy, and only indicate their presence in the 
communication channel. Moreover, only cooperating ASes 
indicate their presence in the communication channel. The 
source AS stores the final P for at least a period of T m = 12 
hours, as it is needed in the protest phase. 

The signatures and MACs, by which each entity authen¬ 
ticates the information of all the previous entities, protect 
against path falsification attempts. A malicious entity cannot 
substitute the information inscribed by previous entities with¬ 
out invalidating the signatures or MACs. To avoid malicious 
entities from truncating on-path ASes, the source AS inserts 
the cooperating ASes on the path ( P[0\.path ). In this way, on- 
path entities cannot truncate on-path ASes, as the source has 
indicated which ASes will cooperate. In addition, the source 
cannot he and remove cooperating ASes from the indicated 
path, as these ASes will inscribe their information and reveal 
their support. Furthermore, the two timestamps indicate the 
validity period of the channel so that complaints are temporally 
confined. 


D. Verifying Proofs of Misbehavior 

In ISection II-Cl we describe how the information in control 
and data plane is used to prove misbehavior. In this section, 
we describe the operations to examine a misbehavior report. 

Recall that the information in the policy contains the trans¬ 
mission properties (CIR and CBS) for the communication 
channel. The data packet headers contain information for the 
actual transmission properties. The transit ASes examine the 
received information as follows. 









Destination 


i. ASes verify the signatures of the source and desti¬ 
nation ASes in the policy packet, by obtaining the 
corresponding keys from the RPKI. 

ii. ASes verify the 4-bit MAC that they inscribed in the 
header. If all verifications succeed, ASes proceed with 
Step (iii). MAC verification failures signal en-route 
misbehavior from a subsequent AS on the path from 
the source to the destination. In the next section, we 
analyze scenarios with on-path malicious ASes. 

iii. The ASes check conformance to the Token Bucket 
properties by running Token Bucket as a policer and 
by using the timestamp and payload length informa¬ 
tion of the headers. 

After the three-step procedure, the AS provides a signed 
admission or rejection for the misbehavior to the reporting AS. 
The destination AS collects the signed responses and sends 
them back to all ASes on the communication channel. 

IV. Protocol Analysis 

This section analyzes the security and scalability properties 
of FAIR. 

A. Security Aspects 

We analyze the security properties of short MACs and then 
describe to which extent FAIR is robust under two different 
threat models. We first consider a strong threat model in which 
all entities can be malicious. We then consider a second threat 
model that is slightly weaker, but specifically designed to 
address current attacks. 

• Threat Model I: Misbehavior is provable at least to the 
benign cooperating ASes adjacent to the destination, 
under the strong threat model in which source, transit, 
and destination ASes can be malicious and collude. 

• Threat Model II: Misbehavior is provable to all coop¬ 
erating ASes on the path, under a weaker threat model 
in which transit ASes are not malicious. 

Our goal to present a deployable high-performance sys¬ 
tem deals with the natural tradeoff between performance and 
security: some related approaches provide stronger security 
guarantees, but come at the cost of introducing considerable 
overhead. See ISection VIII for the details on related work. 

1) On the use of short MACs. Before discussing the two 
threat models in detail, we evaluate the choice of short MACs. 
Specifically, we argue that a very short MAC is sufficient to 
provide accountability proofs in the context of flooding attacks. 
There are two important points to mention: i) The role of the 
MACs in the packet, as mentioned before, is only to provide 
a reminder to the transit ASes that they have forwarded the 
packet. In the context of flooding attacks, we care about an 
aggregate of packets and the collective proof that is constructed 
from this aggregate, rather than from single packets, ii) The 
secret keys used by other ASes are unknown to the attacker. 
This means that an attacker can at best randomly generate 
MACs without a means to check their validity. 

The short length of the MACs does not prevent an attacker 
from generating valid MACs. However, for an 8-bit MAC, 99% 


Source 



Fig. 4: FAIR operation with AS, being malicious. 


of the generated MACs will not verify in the protest phase and 
the misbehavior will thus be detected. 

Taking this approach to the limit, we could use 1-bit MACs 
for our purpose. An attacker would have a 50% probability to 
create a valid MAC. Thus, 50% of the crafted MACs would 
be invalid (compared to 99% previously) and the misbehavior 
is detected because of these invalid MACs. Our choice of the 
MAC lengths is based on engineering the protocol for high 
forwarding performance (byte aligned packet length), as we 
show in ISection V-CI 


2) Threat Model I. We first analyze the scenario of colluding 
ASes and then two scenarios with malicious transit ASes. 


AS Collusion: In this scenario, a transit AS colludes with a 
malicious source AS to conceal an ongoing attack. The source 
is violating the sending policy and transit AS, ( Figure 4} 
corrupts all the MACs of the previous ASes in the packet, 
causing verification failures when the destination protests to 
these ASes. Hence, the policy violation cannot be proven to 
these ASes. The first complaint round is successful only to the 
shaded ASes in |Figure 4[ as AS, cannot corrupt MACs of the 
subsequent ASes on the path. This limits the effectiveness of 
the proposal, however, successful complaints even to a few 
transit ASes yield benefits, as they can for instance install 


blocking filters closer to the source, as depicted in Figure 4 


The above scenario presents the worst case, in which a 
transit AS corrupts all previous MACs. If AS; does not corrupt 
all the previous MACs, complaining is more effective since 
more ASes would acknowledge the attack. Notice that the 
complaint is accepted at least by the benign cooperating ASes 
adjacent to the destination. Hence, collusion with multiple 
ASes does not provide additional benefits to the source, as 
the effectiveness of the proposal depends only on the position 
of the malicious AS that is closer to the destination. 


Packet Replay: In this scenario, we assume that a malicious 
transit AS forwards a packet multiple times to increase traffic 
and thus to blame an innocent source AS. 

A packet replay is indicated through multiple occurrences 
of the same sequence numbers for a given timestamp. Further¬ 
more, the clock deviation check does not allow an adversary 
to store packets and replay at a later time. The 24-bit sequence 
number suffices for more than 16 ■ 10 6 packets and the mono- 
tonically increasing values render multiple occurrences per 
timestamp suspicious. For example, a communication channel 
with a CIR value of 1 Gbps has an average packet-sending rate 
of 325 kpps for the average packet length of 413 bytes (34). 
For an attack where each packet is replayed twice, there are on 
average 10 b packets that belong to each slot of 1 second, but 
the 24-bit field suffices for more than 16 • 10 6 packets. Under 
normal operation each sequence number would show up only 
once, but multiple occurrences indicate a replay. 














A high-sending-rate policy that uses up the available nonce 
space in the slot of 3 seconds would possibly allow an attacker 
to replay packets, but this is very unlikely: For the average 
packet size of 413 bytes it would require a communication 
channel of 17 Gbps for this to happen, which is an unrealistic 
value for a single channel. If such throughput values become 
reality in the future, increasing the sequence number length 
will solve the problem. For instance, 32 bits suffice for over 4 
billion packets. 


The nonce fields are used for detecting the adversary’s 
location on the path: If AS, ( Figure 4) replays packets, then 
the combinations of sequence number and nonce field of only 
the first i — 1 ASes occur multiple times. In other words, the 
location of the attacker can only be between AS; and AS;+i. 
The reason is twofold. First, non-cooperating ASes between 
AS; and ASi+i might replay packets. Second, the attacker (AS;) 
might inscribe nonces in a way that puts the blame on the next 
AS (ASi+i). Hence, the localization cannot identify the attack 
to a specific entity, but all ASes after the replaying AS become 
aware of the approximate location of the attack and can take 
action. 



Trace I 

Trace 2 

Trace 3 

Trace rate (Gbps) 

1.63 

3.72 

3.57 

IPv4 pkt. (bytes) 

747 (99.95%) 

920 (99.96%) 

736 (99.88%) 

IPv6 pkt. (bytes) 

130 (0.05%) 

342 (0.04%) 

155 (0.12%) 

BW overhead 

1.71% 

1.39% 

1.74% 


Fig. 5: Bandwidth overhead of FAIR for three backbone-link 
traces. The reported sizes are mean values and the parentheses 
show the percentage of traffic for each IP version. 


be concealed. The Token Bucket properties in combination 
with the clock deviation check also protect from a coward 
attack l35l : in a coward attack the attacker scales down the 
intensity temporarily to avoid detection. 

Another general attack against accountability frameworks 
consists in falsely blaming benign entities. A malicious desti¬ 
nation can try to convince transit ASes by providing multiple 
times the same packets as evidence of increased traffic. This 
is a variation of a replay attack and the sequence number 
and nonce fields prevent it. Crafting the timestamps will 
cause MAC verification failures and the transit ASes will not 
acknowledge the proof. 


Note that we use sequence numbers and nonce fields to 
detect replay attacks in the protest phase, rather than to drop 
replayed data-plane traffic. 

Packet Injection: In this attack, a transit AS attempts to craft 
fraudulent packets and inject them into the network. This 
attack is prevented thanks to the MACs inserted by the source 
and the transit ASes. Assuming that the adversary has not 
obtained the local secrets of the other entities, its probability of 
inserting only valid MACs is negligible, as discussed before. 
The verification failures of inserted invalid MACs will reveal 
the attack. 


If AS; (Figure 4i injects traffic, the subsequent ASes on 
the path insert their MACs as usual. These MACs will verify 
in the protest phase and hence the shaded ASes in |Figure 4] 
acknowledge the violation, exactly as in the packet replay 
attack. 


3) Threat Model II. Attacks usually originate from malicious 
or vulnerable end hosts inside the source AS; transit ASes 
usually have no incentive to collude with other ASes, nor 
to engage in malicious conduct, such as packet replay. The 
forwarding proof thus remains intact during transit and all 
cooperating ASes on the path from the source to the destination 
acknowledge the attacks. 

Other Attacks. Here we describe some protocol manipulation 
attacks that are specific to FAIR. Since the destination uses the 
received packets as a proof of an attack, the source can craft 
timestamps in the packet, which together with the aggregate 
traffic size do not violate the policy. The clock deviation check 
protects against this, but allows the source to shift timestamps 
by one second, only once though. More specifically, the source 
can send excessive traffic in the slot of one second by putting 
the timestamp of the next second in some packets. In this 
way the maximum burst size violation for one time interval 
is not detected, but it restricts the traffic for the subsequent 
intervals, as it must be lower to conform to the policy’s 
CBS value for the next intervals. A sending rate that exceeds 
the CIR value over any multiple of the time interval cannot 


B. Scalability 

We examine the scalability properties of FAIR in terms of 
bandwidth and storage overhead. Concerning the processing 
overhead, we provide a detailed evaluation in ISection Vl 


1) Bandwidth Overhead. Our proposal comes at the cost 
of increased packet size. The source AS inscribes a constant 
amount of 7 bytes/packet and each transit AS adds another 
1 byte. We envision a FAIR integration with the IP protocol 
and this would require two additional bytes per packet only in 
the case of IPv6 traffic (more details, also on IPv4, follow in 
ISection Vl i. To put this overhead into context, we analyze three 
1-hour packet traces of OC-192 backbone links obtained from 
CAIDA 1341 . We take a pessimistic approach on the AS-path 
length to quantify the overhead and assume it to be 5 hopsQ 
Based on the number of packets in IPv4 and IPv6 and their 
ratio on the link, we calculate the link’s overall bandwidth 
overhead. Figure 5 shows the properties of the traffic on the 
link and the overall overhead: the bandwidth overhead does not 
exceed 2%. This estimation assumes that the AS-path length 
is independent of the packet length distribution. 


2) Storage Overhead. To provide a scalable framework, our 
goal is to reduce the amount of state stored at the forwarding 
devices of cooperating ASes. Source and transit ASes do 
not need to store data-plane related information. The source 
stores one policy packet and a shared key Ksd (16 bytes) 
per communication channel. The total number of ASes in 
the Internet is less than 50,000 (36), which means minimal 
overhead (800 kB) even if there is a communication channel 
with every other AS. 

Furthermore, the transit ASes store only local secret keys 
(independent of any communication channel). As noted in 
ISection IV-AI there is no strict requirement on the frequency 
of changing keys, however, the previous keys are kept to verify 
MACs that were computed earlier. According to the protocol, 

- It I PH Labs report an average length of 3.9 hops for IPv4 and 3.5 hops for 
IPv6 (32) 





















a cooperating AS accepts and examines incoming proofs up 
to a period of T m = 12 hours in the past. Hence, the storage 
overhead depends on the frequency with which the AS changes 
its keys within the 12-hour frame. For example, a transit AS 
that changes its local keys (K,, K,) every minute requires a 
storage capacity of 250 kB for the 12-hour period. 

The most significant storage overhead occurs for the des¬ 
tination AS when storing data packet headers as a proof of 
source misbehavior. The destination can provide the proof to 
the transit ASes up to 12 hours after it received the packets. 
For a destination AS that stores the IP and FAIR packet 
headers of the 1-hour link traces in |Figure 5] the storage 
requirement is 30.2, 56, and 67.3 GB, respectively. For this 
calculation, we assume again an AS-path length of 5 hops 
and took into consideration the different overhead of the IPv6 
header (40 bytes) and the IPv4 header (20 bytes), on top of 
the FAIR header overhead. 

Note that the considerable storage overhead is shifted to 
the destination AS since it is in the destination’s interest to 
be protected from flooding attacks; thus having forwarding 
ASes store the packets would distribute the storage overhead 
in an unfair manner. Moreover, to further decrease the over¬ 
head, destination ASes store only packet headers. Also, the 
destination can choose when to protest about a violation, 
hence it does not have to store headers for 12 hours and 
can regulate the storage requirement. In addition, ASes can 
store compressed proofs of misbehavior only for the violated 
time periods instead of storing the whole set of packets of the 
communication channel. 


V. Implementation and Evaluation 

We describe our protocol in the context of today’s Internet, 
implement a software switch prototype, and evaluate perfor¬ 
mance on a server and a desktop machine. 


A. Integration with IP 


We analyze the deployment of FAIR with IP. IPv6 allows a 
straightforward and elegant implementation by using Extension 
Headers (EHs) El. IPv6 Extension Headers encode optional 
IP-layer information in headers that are placed after the regular 
IPv6 header. They make the protocol extensible by allowing 
support for security, mobility, and other services. 


The IPv6 specification 1371 defines some default EHs 
for additional network-layer services and leaves space for 
new EHs. To implement FAIR, we define a new EH that 
is processed only by egress border routers of cooperating 
ASes. According to the specification, the Hop-by-Hop EH is 
the only EH that must be processed by all network devices, 
whereas other EHs are inspected only by devices configured 
for certain services. This feature allows ISPs to adopt FAIR in 
an incrementally deployable fashion without breaking legacy 
IPv6 traffic. |Figure 6 shows a regular IPv6 header together 
with the FAIR extension. The FAIR EH is placed after the 
regular IPv6 header or after the Hop-by-Hop EH (if present), 
as the IPv6 specification commands. The Next Header field 
(whether in the regular header or in a preceding EH) points to 
the start of the FAIR EH. The content of our EH is what 
ISection IID describes and Figure 2 depicts. To make FAIR 
compatible with IPv6, two additional fields are required: a 



Fig. 6: IPv6 packet with FAIR Extension Header. 


pointer (8 bits) that points to the next EH or to an Upper 
Layer (UL) protocol, and a Header Length field (8 bits) 
that indicates the length of the EH. This translates into an 
additional overhead of 2 bytes. 

Extension Headers are considered an intrinsic part of IPv6 
and the way they are processed by network devices can harm 
forwarding performance. However, IPv6 provides an elegant 
deployment path due to EHs. This feature is not supported by 
IPv4 and a workaround for IPv4 is necessary. 

IPv4 has inherent limitations with regard to extensibility 
which complicates deployment. The FAIR header can be 
implemented as a “shim” layer between the IPv4 header and 
the transport protocol. The border routers of source ASes insert 
the FAIR header after the IPv4 header; border routers of transit 
ASes locate and process the FAIR header, as it starts 20 bytes 
after the IPv4 header; and the border routers of destination 
ASes store and remove the FAIR header before forwarding 
the packet to the destination host. Shim-layer approaches 
typically cause problems due to middleboxes in the source 
and/or destination ASes 1381 . However, note that the FAIR 
header is not visible inside those domains, alleviating such 
concerns. 

B. Software Switch Prototype 

To test the practicality of our proposal, we implement the 
required functionality in software. We recognize a resurgence 
of interest in software switches thanks to their flexibility 
and programmability at low procurement and operational 
costs EMU- Furthermore, recent advances in the software¬ 
switching field demonstrate that these advantages do not come 
at the cost of performance, which has traditionally been the 
Achilles’ heel of software switches. We use the Intel Data 
Plane Development Kit (DPDK) l42l as the packet I/O engine 
and take advantage of the Intel AES-NI (43) - 

The Intel DPDK is a high-performance packet I/O engine 
that provides flexibility and programmability, allowing packet 
processing in user space. DPDK uses polling to avoid the 
overhead of unnecessary interrupts. It provides optimized 
Network Interface Card (NIC) drivers that map packet buffers 
directly in user space to avoid redundant memory accesses 
(zero copy). We choose DPDK for our development platform 
as it efficiently performs packet I/O and allows us to focus on 
the FAIR EH processing. 

The Intel AES-NI is a recent instruction set that uses 
hardware support to speed up encryption and decryption of 





















AES operations. Intel reports a performance of 2.01 Cycles 
Per Byte (CPB) for a 16-byte block AES encryption on an 
Intel Westmere running at 2.67 GHz 11431 . 

We describe the implementation of the necessary compo¬ 
nents for FAIR. To construct the required MACs, we use the 
Cipher Block Chaining mode (CBC-MAC) with AES as the 
underlying block cipher. The CBC-MAC encryption of a plain¬ 
text block depends on the encryption of the previous block; the 
output is the final block. The value for the Initialization Vector 
(IV) is 0. The size of both input blocks and the output block 
is 128 bits (16 bytes). The input length to the CBC-MAC is 
fixed and independent of the AS path lengtlQ. Also, the input 
fits in one block (less than 16 bytes). Furthermore, the input 
length of the MACs in the control plane is fixed as well. We 
use 128-bit encryption keys and keep only the required number 
of bits from the output, as specified in ISection fill 

The source AS of the outgoing traffic has to look up the 
shared key with the destination ( K$d ) and the current packet 
count for the communication channel, as it is used for the 
sequence number ( seqno ). The source uses the shared key with 
the destination in order to compute the MAC. To implement 
these functionalities at line rate, we extend the Forwarding 
Information Base (FIB) to contain not only the egress interface, 
but also the shared symmetric key with the destination and the 
current value for the sequence number. 

This increases the size of the FIB, but it still fits in 
todays SRAM caches, avoiding access to the substantially 
slower DRAM. The size of the extended FIB for today’s 
IPv4 BGP routing table sizes is around 12 MB li45l and for 
IPv6 around 1 MB B31 , which is lower than SRAM sizes 
even on commodity hardware, as we show in our evaluation. 
In addition, the increase in length for each FIB entry does 
not degrade forwarding performance since each FIB entry 
fits into the typical cache line of 64 bytes. Even in case of 
IPv6 addresses, where each entry requires 36 bytes (16-byte 
destination address, 16-byte symmetric key, 3-byte sequence 
number, and 1-byte output interface). 

To generate randomness for the nonce and to mark fields at 
line rate, we need an efficient pseudorandom number generator 
(PRNG). We implement a thread-safe, multicore version of 
the Linear Congruential Generator (LCG) that meets our 
performance requirements. Modern CPUs come with Digital 
RNG (DRNG) hardware implementations |46l that can speed 
up this process significantly El . Unfortunately, our CPUs lack 
this feature. Furthermore, each CPU core has an AES hardware 
unit. We assign each core to handle one port, taking advantage 
of the processing power of today’s multicore systems. For the 
timestamp, we use the least significant bits (LSB) of the Unix 
time. 

We bring these components together on two different 
machines: a commodity server and a low-end desktop. The 
server has a non-uniform memory access (NUMA) architecture 
with two Intel Xeon E5-2680 CPUs that communicate over two 
QPI links. Moreover, each NUMA node is equipped with four 
banks of 16 GB DDR3 RAM. In total, we have 6 dual-port 
10 GbE NICs (PCIe Gen2 x8) that can provide a maximum 
capacity of 120 Gbps. The total cost of this setup is around 


3 CBC-MAC is insecure for variable-length messages El. 


Item 

Model Name 

Qty 

Unit price 

Board 

Intel S2600GZ (2 sockets) 

l 

$670 

CPU 

Intel Xeon E5-2680 (8 cores, 2.7 GHz) 

2 

$1,727 

RAM 

Kingston DDR3 4 GB (1,333 MHz) 

8 

$38 

NICs 

Intel 82599EB X520-DA2 10 GbE 

6 

$450 


Fig. 7: Specification of utilized Server Hardware. 


Item 

Model Name 

Qty 

Unit price 

CPU 

Intel Core i5-3470S (4 cores, 2.9 GHz) 

l 

$170 

RAM 

Hynix DDR3 4 GB (1,600 MHz) 

l 

$45 

NICs 

Intel 82599EB X520-DA2 10 GbE 

l 

$450 


Fig. 8: Specification of utilized Desktop Hardware. 


$7, 000. |Figure 7| summarizes the hardware specification of the 
server machine. 

The desktop machine is a Lenovo ThinkCentre Edge 
3494AZG with an Intel Core i5-3470S CPU with one dual¬ 
port 10 GbE NIC (PCIe Gen2 x8) and a total cost of $1, 200. 
|Figure 8] shows the hardware specification of the desktop 
machine. 


C. Switch Prototype Evaluation 

We evaluate the switching performance of both machines 
and demonstrate that the EH processing incurs minimal com¬ 
putational overhead even for low-end hardware. 

In the experiments, we emulate traffic flows originated by 
a source AS and evaluate the performance of a FAIR-enabled 
border router. We evaluate the worst case, and thus we use IPv6 
that is slower than IPv4 because the Forwarding Information 
Base (FIB) entry is longer than for IPv4; we have observed the 
same forwarding performance also for IPv4 traffic. Moreover, 
we specify random destination addresses for the generated 
flows, eliminating spatiotemporal locality for cache accesses. 
Using random destination addresses captures any performance 
degradation due to key switching with different destination 
ASes. To generate traffic, we use Spirent SPT-N4U-220 as 
our packet generator. The table lookup is performed by an 
implementation of DIR-24-8-BASIC pfel for IPv6 addresses. 
We generate the FIB from a BGP routing table snapshot 
(November 2014) from RIPE RIS, with 18k unique IPv6 
prefixes ES). 

First, we evaluate the performance of a single 10G port 
for three packet sizes; then we enable all ports. Finally, we 
evaluate performance with all ports enabled and for varying 
packet sizes. All the experiments are conducted on the server 
and the desktop platforms. 


1) Single-port experiment. First, we test the switching per¬ 
formance of one port for three packet sizes: 68, 128, and 1024 
bytes. Minimum-sized packets, 68 bytes, translate to a higher 
packet rate and are the worst case for the EH processing. The 
minimum length for IPv6 packets with the FAIR EH is 68 


bytes (instead of 64) due to the additional information. Figure 9 


shows the switching performance for the server and the desktop 
platform. 


The highest packet rates for the three packet sizes are 
14.20 Mpps, 8.45 Mpps, and 1.20 Mpps on a 10 GbE link; 





















Server Desktop 

Fig. 9: Switching performance of the server and the desktop 
for one port activated, and 68, 128, and 1024-byte packets. 



Server Desktop 


Fig. 10: Switching performance of the server and the desktop 
for all ports activated, and 68, 128, and 1024-byte packets. 


we refer to these values as the line-rate performance. The 
baseline for the experiments is the switching performance of 
legacy IPv6 traffic (only table lookup and forwarding). The 
figure shows that the EH processing degrades performance 
by only 1% for minimum-sized packets on both machines. 
The figure also shows the line-rate performance (blue line) 
and the minimal baseline degradation due to the table lookup 
and the high packet rate for the 68-byte case. For the longer 
packet sizes, the switching performance reaches the line rate 
on both machines. The single-port experiment demonstrates 
that switching performance is close to optimal for one port, 
even on low-end hardware. Next, we increase the switching 
load. 


2) All-ports experiment. To demonstrate that the FAIR EH 
processing scales for increasing packet rates, we activate all 
ports; each port is served by a different CPU core. Again we 
use the same three packet sizes. Figure 10 shows the results. 


We use a different scale in the figure for the two machines, 
since they accommodate a different number of ports. The 
packet line rates for the server (12 ports) and the three 
packet sizes are 170.4 Mpps, 101.4 Mpps, and 14.4 Mpps, 
respectively. The packet line rates for the desktop (2 ports) 
and the three packet sizes are 28.40 Mpps, 16.90 Mpps, and 
2.40 Mpps, respectively. We see that throughput scales for 
multiple ports and FAIR switches at baseline performance 
for the three packet sizes, on both machines. The experiment 
demonstrates how switching performance scales for increasing 
packet rates, even for the low-end hardware. However, we 
notice a higher baseline degradation for 68-byte packets: in 
the one-port experiment, the switching performance was at 
96% of the line rate, whereas now it is around 80%. The 
explanation is that our I/O subsystem hits a bottleneck when 
both ports of a NIC receive packets at the maximum packet 
rate. The bottleneck exists irrespective of FAIR: the PCIe Gen2 
x8 interface of our NICs cannot sustain this packet rate when 
both ports are active. The packet rate of each port is capped 
at 11.55 Mpps. Cuckooswitch ll39l uses the same NICs and 
reports the same limitation. 


3) CPU as the bottleneck. To bypass the I/O bottleneck and 
stress the limits of the CPU, we assign the traffic from two 
ports of different NICs to one core; this makes the CPU the 
throughput bottleneck. For minimum-sized packets, the CPU 
handles 21.62 Mpps out of the maximum 28.40 Mpps. Hence, 
one CPU core can process traffic from more than one 10 GbE 
port that receives packets at the maximum packet rate. 



Fig. 11: Switching performance for all ports. 


Next, we show that for increasing packet sizes, FAIR 
saturates line-rate bandwidth and achieves 120 
20 Gbps for the server and desktop respectively, 
shows the throughput for 68, 128, 256, 512, 1024, 
byte packets. We omit the line-rate line; for all measurements 
— except the 68 byte packet — it is identical to the drawn 
lines. Hence, as we increase the packet size and the packet 
rate drops, IPv6 baseline and FAIR performance is at 100% 
line rate. 


Gbps and 
Figure 11 
and 1518- 


VI. Protection from DDoS Attacks 

FAIR, as an accountability framework, does not provide 
active protection from attacks, as it does not enforce specific 
behavior when an attack is detected. This section describes 
a more radical application of FAIR that enforces and pushes 
higher security standards to the edge of the Internet. Further¬ 
more, the section illustrates how FAIR can be combined with 
active defense mechanisms. 

A. Suspicious Bit 

The April Fool’s proposal of the “evil bit” 1201 describes 
a security mechanism from an idealist’s point of view: data 
packets carry a security flag - the evil bit - to indicate 
malicious intent; the flag is set by the malicious senders 
themselves. 

We propose a more realistic security mechanism, the suspi¬ 
cious bit that is set by transit ASes to indicate suspicious traf¬ 
fic. With such a mechanism in place, the traffic itself becomes 
the indicator of possibly malicious behavior and incentivizes 
transit ASes to take action. For instance, an AS can drop or 
deprioritize suspicious traffic in case of congestion, ensuring 
better service for its benign customers. In addition, flagging 
traffic due to an attack on one victim provides protection to 
other potential victims as well. 
































































Fig. 12: The suspicious bit identifies traffic from a portion of 
the network with poor security practices. 


An immediate question is how ISPs distinguish benign 
from suspicious ASes in order to flag their traffic. We leverage 
FAIR as a building block to address this question. FAIR’S 
initial sending policy negotiation provides a clear line for 
detection of misbehavior; the FAIR header in the data packets 
provides the corresponding accountable proofs of misbehavior. 

Another question is how ISPs are incentivized to flag their 
misbehaving customers. The answer to this question lies in the 
competitive environment in the Internet ecosystem. Recall that 
FAIR’S accountable proof of misbehavior is received by all on- 
path ASes. If an ISP does not flag its provably malicious transit 
traffic, then the next AS on the path will flag all of the traffic of 
the previous AS. We believe that the threat of collateral damage 
and the harsh competitive Internet market pushes ISPs to 
mark their customers’ traffic. If innocent customers experience 
packet drop because of their ISPs’ poor security practices, they 
have an incentive to switch to a more reliable ISP, if possible. 

We emphasize that ISPs do not have to drop suspicious 
traffic right away for two reasons. First, the suspicious bit 
indicates only that the traffic is suspicious (not necessarily 
malicious) and thus gives incentives to take action under 
certain conditions (e.g., drop it in case of congestion). Second, 
under the strong threat model, an adversary could set the bit 
for legitimate traffic to make another ISP drop the traffic. 
Consequently, setting the suspicious bit for legitimate traffic 
would not be a useful attack strategy. In addition, today’s 
Internet is opaque to loss anyway ED, and hence the adversary 
can directly drop the traffic and evade detection. 


We demonstrate the suspicious bit application by means of 


Figure 12 The illustrated network topology shows malicious 


ASo violating the sending policy negotiated with benign AS,,. 
ASi is the ISP of the malicious ASo and other benign ASes. It 
hence provides transit to more than a single customer. Assume 
that ASi has received a proof of misbehavior for ASo: AS n 
has reported malicious traffic to ASi. In the ideal case, ASi 
would mark traffic from ASo as suspicious, warning other 
entities in the network. If, however, ASi does not mark the 
suspicious traffic, then AS 2 will mark all the traffic from ASi 
as suspicious. 


This overstatement, however, means that also traffic from 
the benign customers of ASi gets flagged as suspicious, 
which will lead to collateral damage if a downstream ISP 
decides to drop traffic. By flagging traffic, AS 2 informs other 
entities in the network (shaded part) that some portion of the 
network (dashed part) might be misbehaving. This practice will 
incentivize ASi to behave correctly and to flag the traffic of 
its misbehaving clients, thereby protecting its benign clients. 


As a consequence, the stub ASes are pushed to deal with 
their internal security issues (e.g., botnets inside an AS or 
misconfigured services) to protect the innocent flows from 
being dropped. 

Forwarding with the Suspicious Bit: We show the infor¬ 
mation and data structures when forwarding traffic under the 
SB application. 

• Suspicious Bit (sb): the SB flag, used to mark a packet 
as suspicious, is the most significant bit of the nextAS 
pointer in the FAIR header. This means that routers 
will check and update the 7 least significant bits of the 
pointer, which suffice to encode AS-paths of length up 
to 128 hops. 

• Suspicious Sources ( sus_sources ): set of addresses for 
which the AS has acknowledged the violation. 

• Suspicious Ports ( sus_ports ): set of the switch’s ports 
that receive traffic from an insecure part of the net¬ 
work. We refer remaining ports of the switch as non- 
suspicious. 

In the following, we describe how this information is used 
to realize the suspicious bit application. Note that the SB 
does not enforce a specific action, hence the transit AS can 
forward, drop, or delay traffic based on its traffic engineering 
and security policies. [Procedure~4l provides the pseudocode for 
traffic forwarding with the suspicious bit. 

• If incoming traffic arrives at a non-suspicious port: 

o if the SB is set then forward/drop/delay traffic, 
o if the SB is not set and the source address 
belongs to the suspicious sources then add the 
port to the suspicious ports. Set the SB and 
forward/drop/delay traffic. 

• If incoming traffic arrives at a suspicious port: 

o if the SB is set, remove the incoming port from 
the suspicious ports. In this way if previous 
ASes that did not flag traffic start flagging, 
their whole traffic is not flagged as suspicious 
anymore. Then forward the traffic, 
o if the SB is not set, then set the SB. Then 
forward/drop/delay. 

B. Active Defense 

We describe how forwarding accountability serves as a 
building block for active DDoS defense. Transit ISPs can 
simply drop traffic from malicious ASes, providing a primitive 
DDoS defense. However, accountable proof of misbehavior 
can be combined seamlessly with more sophisticated protec¬ 
tion schemes. 

Filtering defense proposals (e.g., Stoplt fl4l . AITF ]T5l . 
and Pushback ESI) demonstrate the effectiveness of a dis¬ 
tributed and cooperative approach to control certain traffic 
flows by asking upstream routers to install filters. These 
approaches assume that upstream routers are willing to install 
such filters. However, at the inter-domain level this is a strong 
assumption. 

ISPs are harsh competitors and are mutually distrusted 
entities. In addition, ISPs earn revenue by forwarding traffic. 





Procedure 4: Forwarding packets in the SB application 

procedure FORWARD (pkt_hdr, fair, port_in) 

> pkt_hdr contains the network-layer packet header 

> fair is the FAIR header 

> port_in is the ingress port of the packet 
if port_in 0 sus_ports then 

if fair.sb then forward/drop/delay traffic 
else 

if pkt_hdr.src_addr € sus_sources then 
sus_ports <— sus_ports U {port_in} 
fair.sb <— 1 
forward/drop/delay traffic 

else 

forward traffic 

else 

if fair.sb then 

sus_ports <— sus_ports — {port_in} 
forward traffic 

else 

fair.sb <— 1 
forward/drop/delay traffic 


regardless of the intent of the traffic. Furthermore, filtering 
resources at forwarding devices are limited and should be 
used cautiously. Hence, spending filtering resources for targets 
outside the AS boundaries is an assumption that does not hold. 
Stoplt fl4l recognizes this fact for inter-domain filtering re¬ 
quests and leverages shared keys to authenticate such requests. 
However, no filtering proposal obtains proof of misbehavior in 
order to install such filters. Malicious ASes could try to exhaust 
filtering resources of other ASes. 

FAIR allows an AS to provide misbehavior proof to other 
ASes and convince them to install filters. Furthermore, ac¬ 
countability can lead to novel contractual regimes and SLAs 
that formally describe cooperative mechanisms to address the 
flooding attacks. 

We discuss the deployment and operation of FAIR. The 
prominent advantage of FAIR is founded on the fact that 
collateral damage can be leveraged to push ISPs to enforce 
higher security standards, e.g., to deal with internal security 
threats such as botnets or vulnerable components. Collateral 
damage mainly stems from today’s Internet architecture, and 
specifically from its lack of accountability. In particular, in 
distributed attacks, the misbehaving source end hosts cannot 
be identified. 

FAIR identifies such malicious sources at the AS granular¬ 
ity with the consequence that also innocent flows get classified 
as malicious. Clearly, harming innocent flows is undesirable, 
but provable AS misbehavior gives incentives for ISPs to take 
action against such malicious traffic (e.g., deprioritize or drop 
it). This holds the whole AS accountable for misbehavior 
and puts it under pressure to deal with its security issues, 
rather than delegating flooding protection to the victim. Hence, 
provable misbehavior turns collateral damage on its head by 
using innocent flows as a way to pressure ASes to deal with 
their security issues. 


protocols. The introduced overhead, although not negligible, is 
within reach of today’s processing and networking capabilities. 
In addition, given that source and destination ASes set up a 
sending policy, the destination can protest and prove misbe¬ 
havior even if only one transit AS supports FAIR. Thus, ASes 
can deploy FAIR independently without global coordination. 

On the downside, forwarding devices on the data path 
will need to support additional processing mechanisms, which 
translate to upgrades and costs. Furthermore, the considerable 
storage overhead for destination ASes can further increase 
operational costs. Finally, the requirement for a policy con¬ 
struction that defines the characteristics of the transmission 
constitutes a deviation from today’s communication model. 

D. Operational Assumptions 

In the high-level overview of FAIR ( ISection III) , we pre¬ 
sented a router-level communication model between the source 
and destination AS in which we assumed that all traffic flows 
originated by the source AS follow the same AS-level path 
towards the destination. We relax this assumption of a line 
topology, as this model does not reflect reality: each border 
router decides independently on the next AS hop. Moreover, 
the interaction of inter-domain routing and intra-domain traffic 
engineering (e.g., load balancing) leads to different AS-level 
paths between the source and destination ASes. Therefore, in 
FAIR, a communication channel is identified by the AS path 
and not by the source-destination AS tuple. 

Furthermore, two ASes can peer at multiple Points of Pres¬ 
ence. Consequently, the source AS might have to coordinate 
the sending rates if there are multiple peering points with the 
next AS. Readily available approaches deal with such traffic 
engineering tasks: Segment Routing Centralized Egress Peer 
Engineering developed by Cisco ED and Intelligent Route 
Service Control Point solutions El are such examples. 

Routing instability that forces source and destination to 
reestablish a communication channel over a new path is not 
a notable concern. Studies show that the majority of network 
routes are stable from tens of minutes to days l52ll53ll . Despite 
ISPs’ traffic engineering and the existence of short-lived routes, 
long-lived routes are used 96% of the time ll52l . 

Furthermore, today’s border routers are not required to 
perform cryptographic operations on data-plane traffic. How¬ 
ever, the recent advances in cryptographic engines, such as 
Intel AES-NI ||43| . allow efficient cryptographic operations 
even for commodity machines, as we have demonstrated in 
ISection V-CI 

Moreover, schemes that increase the packet length (the 
border router of the source AS adds the FAIR header) need 
to take into account correct MTU discovery. In case a large 
packet requires fragmentation, the border router of the source 
AS can respond with an MTU size small enough, so that the 
FAIR header can be added without concerns. 


C. Deployment Path E. Security Concerns 

FAIR is deployable in the context of today’s Internet as it In this paper, we focused on the security properties of the 

does not require architectural changes. More precisely, FAIR accountability framework and not on other security aspects 
is compatible with today’s protocols and especially with IPv6 (such as source accountability or flooding attacks on the 
extension headers, which were designed for deploying novel channel setup). Source address spoofing is a well-known and 









studied problem with best current security practices (BCP 
38/84 EH El) that should be followed by administrators. 
Denial-of-Capability (DoC) attacks - flooding the request 
channel of capability defense systems - have been demon¬ 
strated along with proposals for defense nuua, which can 
be used as protection from flooding the FAIR setup channel. 
We stress that our key ideas are compatible with other future 
Internet proposals that address natively the aforementioned 
security concerns (25l l26l . 

VII. Related Work 

We describe some major accountability and DDoS defense 
schemes; comprehensive surveys about DDoS defense can be 
found in Zargar et al. (56l and in Mirkovic et al. E3. 

Accountability mechanisms are building blocks to hinder 
DDoS attacks, rather than active defense mechanisms. For 
example, AIP Q is a network architecture based on account¬ 
ability, with a two-level flat addressing structure that allows for 
using self-certifying addresses (the hash of the corresponding 
public keys). IPA ||58l is a more lightweight approach that 
binds an IP prefix to the public key of an AS by leveraging the 
DNSSEC infrastructure. The secured bindings are piggybacked 
in BGP messages and get distributed in a protocol-compliant 
and incrementally-deployed way. Passport (8] is a network- 
layer source authentication system that authenticates the source 
of a packet to the granularity of the origin AS. Symmetric 
key cryptography is used and packets are checked only at 
administrative boundaries. Using accountable source addresses 
as a building block, additional defense schemes are proposed. 
For example, a shut-off protocol is proposed Q, where a host 
can instruct the network interface of an attacker to stop packet 
transmission. However, this pushes DDoS defense to the hosts, 
assuming that all hosts recognize such a shut-off protocol. 

Simon et al. propose AS-based accountability as a cost- 
effective DDoS defense (59]. Moreover, the authors propose 
an evil bit in the packet headers. The proposal works for a 
group of participating ASes, assuming pairwise and transitive 
trust between them. The evil bit is set whenever traffic enters 
from outside the island of the participating ASes. However, the 
inferred threat model is weak, since a single compromised AS 
inside the group of participating ASes limits the effectiveness 
of the proposal. In addition, the system introduces considerable 
upgrades in terms of infrastructure and requires new Customer 
Relationship Management (CRM) systems. 

Other accountability schemes used for debugging and 
forensics introduce prohibitive overhead for deployment in the 
data plane. SNP libTJI . PeerReview |6TI . and NetReview l62l 
keep detailed logs of exchanged messages and introduce 
substantial overhead in terms of processing, storage, and 
bandwidth. 

An alternative approach to identify the source of an attack 
is to identify the path(s) traversed by malicious traffic. In 
IP traceback I2Y1 , downstream routers probabilistically mark 
packets with partial path information. The victims combine 
the partial path information in the packets to reconstruct the 
path(s) to the source(s) of the attack. The proposal yields 
high computational overhead for path reconstruction at the 
victims and a high false positive rate even for small scale 
DDoS attacks (63). In addition, IP traceback operates under 


a weak threat model, in which downstream routers need to 
be trusted. Incremental proposals optimize the computational 
overhead and operate under a stronger threat model that 
includes malicious routers 1631 . Hop-Count Filtering (64l is 
a host-based approach that discards spoofed DDoS traffic. The 
main idea is that the only IP header information that cannot be 
influenced by an attacker is the TTL field. Hence, spoofed IP 
packets will most probably have inconsistent hop-count values 
with the IP addresses being spoofed. FAIR borrows ideas from 
these schemes, as the packets contain proofs of misbehavior 
if the source violates the acknowledged traffic profile. The 
destination then sends the proofs back to the corresponding 
ASes to prove the misbehavior. 

There are two main approaches for active defenses against 
DDoS attacks: capabilities and filtering. Capability propos¬ 
als 11014121 [65 1 let the destination explicitly authorize traffic 
that it desires to receive. Our approach is inspired by capability 
schemes — not for proving traffic legitimacy, but for collecting 
and providing proofs to each transit AS on the path. The first 
challenge for a victim is to distinguish between malicious and 
benign traffic sources (65]. Benign traffic sources get short¬ 
term authorizations - capabilities - from the destinations and 
put them into the packets, so that the legitimacy of traffic 
can be verified. Capability proposals introduce considerable 
complexity and are susceptible to DoC attacks iflOl . To ad¬ 
dress DoC, TVA H2 tags each packet with the identifier 
of the ingress point to an AS and fair-queues packets at 
each router according to this identifier. Portcullis lfl2l uses 
puzzles (computational proofs of work) to provide fair sharing 
of the request channel. NetFence (66l is a hybrid system 
and introduces a secure congestion policy feedback combined 
with elements from capability-based systems. Most capability 
proposals assume a mechanism that distinguishes malicious 
from benign traffic and the effectiveness of these proposals is, 
at most, as good as this assumed mechanism. In FAIR, we use 
a traffic profile that draws a clear line between malicious and 
benign behavior, and use the proofs in the packets to push the 
edge ASes to address their security problems. 

The second class of active DDoS defense mechanisms, 
filtering proposals, relies on stopping malicious flows in the 
network before reaching the victim. Stoplt 11141 uses a closed- 
control and open-service architecture to defend from attacks 
that prevent filter installation. End hosts can send Stoplt 
requests only to their access routers and each AS has a Stoplt 
server that handles Stoplt requests. AITF 031 installs filters in 
routers as close as possible to the attacking sources, rather than 
in backbone routers. Pushback (l6l detects a malicious traffic 
aggregate and controls it at a single router and in a cooperative 
manner by asking upstream providers to stop the malicious 
aggregate. Such filtering schemes assume cooperation among 
ISPs and that ISPs are willing to provide some of their filtering 
resources to protect remote victims. However, this is an unreal¬ 
istic assumption in today’s competitive Internet ecosystem and 
we consider the accountable proof of misbehavior as a way to 
convince ISPs to install filters. Alternatively, such proof can 
lead to new contracts among ISPs with regard to security. 

VIII. Conclusion 

This paper has presented FAIR, an attempt to answer the 
question on how to incentivize ISPs to adopt stricter security 


policies and thereby to secure the insecure edge of the Internet 
where most of today’s security problems are rooted. 

FAIR leverages forwarding accountability to prove to tran¬ 
sit ISPs on the path from the source to the destination that they 
have forwarded (malicious) traffic. Using FAIR’S accountable 
proof of misbehavior, we have presented an application - 
the suspicious bit - that incentivizes ISPs to mark traffic 
from their suspicious customers as such and thereby inform 
other entities in the network. FAIR comes with less than 2% 
bandwidth overhead and without any storage overhead for the 
transit ISPs. Furthermore, FAIR is incrementally deployable in 
today’s Internet, and it gives incentives for early adoption. 

We have implemented a FAIR software switch that pro¬ 
cesses packets at the line rate of 120 Gbps, and forwards 140M 
minimum-sized packets per second. 
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